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1  Introduction 


A  search  of  a  decision  tree  can  be  used  to  solve  complicated  problems 
involving  multiple  decisions.  It  is  the  only  known  effective  approach 
to  computer  chess,  for  example.  The  method  typically  operates  on  the 
brink  of  combinatorial  explosion,  however.  In  its  basic  form  its 
computation  time  increases  exponentially  or  factorially,  depending  on 
the  number  of  choices  at  each  level  of  the  tree.  For  that  reason, 
considerable  effort  is  often  spent  in  reducing  the  size  of  the  tree. 

Donald  Knuth  has  pointed  out  in  [KNUT75]  that  the  efficiency  of 
backtracking  algorithms,  to  which  decision-tree  search  belongs,  is  very 
sensitive  to  small  modifications.  We  have  devised  an  efficient 
backtracking  method  for  one  application,  and  feel  it  should  be  recorded. 

We  encountered  a  tree  search  problem  while  investigating  a  database 
performance  question. 

Database  management  systems  (DBMS)  control  and  facilitate  access  to  a 
collection  of  data  that  is  integrated  and  shared  [DATE81].  Concurrency 
is  the  simultaneous  or  interleaved  execution  of  more  than  one  process. 
A  transaction  is  the  logical  unit  of  execution  in  a  database  system; 
examples  would  include  displaying  the  balance  in  one  account,  posting 
interest  to  all  accounts,  or  finding  all  those  items  from  a  particular 
supplier  where  the  inventory  has  fallen  below  the  reorder  point. 
Concurrency  control  is  the  handling  of  concurrent  transactions  so  as  to 
produce  the  same  results  as  nonconcurrent  execution  [DATE83,  BERN81]. 


Sequential  machines  perform  one  computation  at  a  time.  Most  existing 
machines  are  sequential.  The  second  and  third  transactions  described 
above,  however,  involve  performing  the  same  operation  on  many  data 
items.  Making  such  transactions  into  sequences  involves  choosing  an 
order.  If  some  of  the  individual  data  items  are  unavailable  at  certain 
times  because  of  being  used  by  other  transactions,  the  choice  of  order 
is  important  to  performance. 

1.1  Optimality 

We  wish  to  determine  the  time  required  for  the  processing  of  a 
transaction  provided  the  optimal  order  of  access  is  used.  No  actual 
transaction  manager  can  have  sufficient  information  to  achieve 
optimality  in  all  cases,  but  optimality  provides  a  useful  standard  of 
comparison. 

However,  even  given  knowledge  of  when  each  data  item  will  be  locked, 
computation  of  optimal  time  is  not  trivial. 

2.  The  algorithm 

We  decided  to  develop  an  algorithm  that  would  always  produce  the  correct 
result  and  would  nearly  always  compute  it  in  acceptable  time. 

2.1  Decision  tree  search 

One  way  of  finding  an  optimal  solution  to  a  complicated  problem  is  to 
create  a  decision  tree  and  search  it  exhaustively. 


2.1.1  Creating  a  decision  tree 


A  tree  is  a  directed  acyclic  graph  in  which  one  node  (the  root)  has  no 
parent  and  each  other  node  has  exactly  one  parent.  Intuitively,  it  is  a 
diagram  of  a  branching-out  from  a  starting  point.  A  decision  tree 
represents  a  series  of  decisions,  with  branches  representing  particular 
choices.  Given  three  data  items,  A,  B,  and  C,  Figure  1  shows  a  decision 
tree  for  order  of  processing.  The  leftmost  branch  represents  A,  B,  C. 
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Figure  1 


2.1.2  Exhaustive  search 

Assume  each  terminal  node  has  a  value.  In  the  example,  the 
be  time  required  to  process  in  that  order.  To  find  the 


value  would 
minimum  of 


those,  one  could  use  the  recursive  function  Search: 


Function  Search(Tree  :  Tree__type)  :  Integer; 

Var  Val ,  Min  :  Integer;  Pos  :  Tree_type; 

Begin 

If  this  is  a  terminal  node  then 
Search  :=  Value  of  this  node 
Else  begin 

Min  :=  Maxint; 

While  Possibilities  remain  untried  do  begin 
Select  an  untried  choice,  called  Pos; 

Val  :=  Search(Pos); 

If  Val  <  Min  then  Min  :=  Val 
End; 

Search  :=  Min 

End 

End; 

Algorithm  1 


This  algorithm  always  produces  correct  results,  but  operates  in  0(N!) 
time,  where  N  is  the  number  of  data  items.  This  is  not  acceptable 
performance. 


2.1.3  Tree  pruning 

The  performance  of  tree-searching  algorithms  may  be  improved  by 
recognizing  branches  that  do  not  contribute  to  the  result  and  not 
searching  those  branches.  This  is  called  pruning.  In  the  most  general 
case,  where  only  terminal  nodes  have  values  and  no  lower-bound 
calculations  may  be  made,  pruning  is  not  possible.  As  more  knowledge  of 
the  actual  situation  becomes  available,  however,  some  pruning  becomes 
possible . 


We  have  found  ways  to  prune  away  nearly  the  entire  tree. 


2.1.4  Lower  bound 

A  valid  lower  bound  on  the  value  of  a  tree  (optimal  time,  in  this  case) 
can  greatly  reduce  the  time  needed  to  search  the  tree.  As  soon  as  a  way 
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is  discovered  to  achieve  the  lower  bound,  the  search  may  be  abandoned 
since  no  better  result  can  be  achieved.  Also,  if  a  path  has  already 
been  found  with  a  total  cost  as  low  as  can  possibly  be  achieved  in  this 
branch,  the  search  of  this  branch  may  be  abandoned.  Since  these 
considerations  apply  at  any  level  of  the  search,  we  may  express  them  as 
another  recursive  function. 


Var 

Path_cost  :  Integer;  {  Initialize  to  0  } 

Cutoff  :  Integer;  {  Initialize  to  Maxint  } 

Function  Search(Tree  :  Tree_type)  :  Integer; 

Var 

Unit_cost,  Best_Path,  Lowerbound,  Pathtime  :  Integer; 

Which  :  Tree_type; 

Begin 

If  this  is  a  terminal  node  then  begin 

Unit_cost  :=  cost  associated  with  this  node; 

If  path_cost+Unit_cost  <  Cutoff  then 
Cutoff  :=  Path_cost  +  Unit_cost; 

Search  :=  Unitcost 

End 

Else  begin  {  Choices  remain  } 

Best_path  :=  Maxint; 

Compute  Lowerbound ; 

If  Path_cost  +  Lowerbound  <  Cutoff  then  begin  {  Cutoff  } 
Arrange  the  possible  choices  in  a  good  order; 

While  choices  remain  and  (Best_Path> Lowerbound)  do  begin 
Select  next  possibility,  call  it  Which; 

Unit_cost  :=  cost  associated  with  Which; 

Path_cost  :=  Path_cost  +  Unit_cost; 

Pathtime  :=  Search( Which) ; 

If  Pathtime  <  Best_Path  -  Unit_cost  then 
Best_Path  :=  Pathtime  +  Unit_cost; 

Path_cost  :=  Path_cost  -  Unit_cost 

End 

End; 

Search  :=  Best_Path 

End 

End; 


Algorithm  2 

2.2  Optimization  under  Algorithm  2 

The  performance  of  Algorithm  2  depends  on  two  factors: 


1.  The  ordering  of  the  choices 


2.  The  accuracy  of  Lowerbound 

2.2.1  Selection  order 

If  only  one  branch  of  the  tree  produces  optimal  time,  we  would  like  to 
examine  that  branch  early.  If  we  always  search  the  wrong  branch,  we 
still  have  to  examine  the  entire  tree!  A  good  a  priori  ordering  is 
possible  in  our  application.  Of  course,  if  we  could  guarantee  selecting 
the  best  order  beforehand  we  would  not  need  to  search  the  tree,  but  we 
have  discovered  no  method  to  achieve  that. 

2.2.2  Lowerbound 

A  valid  lower  bound  for  a  tree  search  will  never  exceed  the  actual  value 
of  the  tree.  Given  an  invalid  quantity  as  Lowerbound,  Algorithm  2  will 
return  that  instead  of  the  correct  answer.  On  the  other  hand,  a  valid 
lower  bound  which  can  never  be  achieved  will  result  in  no  pruning.  The 
greatest  lower  bound  of  the  value  of  the  tree  is  in  fact  the  value  of 
the  tree,  and  this  is  the  only  value  that  results  in  any  pruning.  Our 
computation  can  be  very  fast,  provided  we  already  know  the  answer. 

This  is  much  more  helpful  than  it  sounds,  though,  because  it  holds  at 
all  levels  of  the  tree.  Even  if  we  can  do  no  pruning  at  the  top  level, 
we  may  prune  very  severely  at  the  next. 

A  perfect  algorithm  for  determining  Lowerbound  would  eliminate  the  need 
for  a  tree  search. 


3  Our  application 


We  wished  to  apply  tree  search  with  pruning  to  our  database  application. 
To  explain,  we  must  first  tell  something  about  the  application  itself. 

3.1  The  simulation 

We  have  simulated  algorithms  for  database  lock  managers  and  the  routines 
that  use  them.  The  various  routines  simulate  processing  simulated 
transactions.  The  important  features  of  a  transaction  in  the  simulation 
have  to  do  with  the  various  data  items  accessed;  we  call  these  Lockable 
Units,  or  LU's. 

A  transaction  has  some  number  of  LU's.  This  number  is  specified  as  a 
parameter.  Each  LU  has  associated  with  it  a  processing  delay,  which 
represents  the  time  required  to  process  the  data  in  that  unit.  Each  LU 
may  also  have  some  adverse  activity.  That  represents  other  transactions 
accessing  the  unit  in  a  way  incompatible  with  our  transaction's  planned 
access.  These  quantities  are  generated  at  random.  Some  LU's  are 
represented  as  having  fixed-length  queues;  these  are  very  high-activity 
data  items.  There  is  a  minimum  time  required  to  acquire  any  data  item, 
which  we  have  set  at  one  time  unit.  Table  1  represents  an  example  of  a 


transaction . 


Transaction  (*  =  steady-state  queue  of  given  length) 
Unit  Delay  Activity  Activity  Activity 


1  10  *  86 

2  4  90  -  247  250  -  .  J5  330  -  445 

3  8  •  96 

4  4  220  -  28 2  310  -  393  520  -  579 

5  12  150  -  276  570  -  630 

Table  1 

4  The  method 

To  find  optimal  time,  we  first  assume  that  all  queues  are  entered  at 
transaction  initiation,  thus  changing  all  asterisks  in  Table  1  to 
zeroes,  and  then  perform  a  tree  search. 

4.1  Ordering  of  alternatives 

At  a  given  moment,  each  lockable  unit  is  in  one  of  three  states: 

1.  Available  now,  but  will  become  unavailable. 

2.  Available  now  and  at  all  future  times. 

3.  Not  now  available. 

We  select  first  those  in  state  1,  in  ascending  order  of  when  they  will 
become  unavailable;  then  state  2,  in  ascending  order  of  processing 
delay;  and  then  state  3,  in  order  of  when  they  will  become  available. 
That  is  an  optimal  order  a  high  percentage  of  the  time.  The  example 
transaction  would  be  ordered  initially  2-5-4-1-3. 

4.2  Computation  of  Lowerbound 

Optimal  performance  for  the  example  transaction  is  105  time  units.  LU's 
2,  5*  and  4  are  acquired  and  processed  in  23  time  units.  LU1  is 
acquired  at  time  86,  and  processing  is  completed  at  96.  LU3  is  then 
immediately  available,  so  acquiring  it  takes  one  time  unit;  processing 
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it  takes  8,  for  a  total  of  105 


We  compute  Lowerbound  as  follows: 


Create  a  record  for  each  remaining  LU,  consisting  of  a  field 
representing  the  time  necessary  to  acquire  a  lock  on  that  item 
(LU.When_avail )  and  a  field  for  its  processing  delay  (LU. Delay). 
Sort  on  When_availf  descending. 

Cum__Delay  :=  0; 

Lowerbound  :=  0; 

While  records  remain  do  begin 
Get  an  LU  record; 

Cum_Delay  :=  Cum_Delay  +  LU. Delay; 

If  LU.When_avail  +  Cum_Delay  >  Lowerbound  then 
Lowerbound  :=  LU.When_avail  +  Cum_Delay; 

Cum_Delay  :=  Cum_Delay  +  Min_lock_acquisition_time 

End 

Algorithm  3 


Testing  this  with  the  example  transaction  shows  why  the  last  line  in  the 
While  is  necessary. 


Unit 

Delay  When Avail 

CumDelay  1 

CumDelay  2 

Col  .2+Col  .3 

Lowerbnd 

3 

8 

96 

8 

9 

104 

104 

1 

10 

86 

19 

20 

105 

105 

2 

4 

1 

24 

25 

25 

105 

4 

4 

1 

29 

30 

30 

105 

5 

12 

1 

42 

43 

43 

105 

Table  2 
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APPENDIX  A 


Optimal  Simulator  Using  Tree  Search  With  Cutoffs 


{ $ INCLUDE : ' B : LOCGLBLS. DOC  * } 

{$ INCLUDE B : LOCTMCAL . DOC ' } 

{*  Module  containing  code  to  simulate  OPTIMAL.  *} 

. . . . . 

Module  Locopt; 

Uses  Globids,  Tmcal; 

Function  Max (A,  B  :  Integer)  :  Integer;  Extern; 


Procedure  Optimal (LU_Num  :  Integer); 

. . . 

{*  OPTIMAL  determines  a  lower  bound  on  processing  the  given  *} 

{*  transaction  using  locks.  By  assumption  it  uses  only  as  *} 

{*  many  lock  requests  as  there  are  lockable  units  and  gets  *} 

{*  into  all  queues  at  initiation  time.  It  does  a  search  of  *} 

{*  the  decision  tree  of  orders  of  lock  requests  to  find  one  *} 

{*  that  results  in  the  least  delay.  The  tree  search  selects  •} 

{*  a  first  order  of  requests  that  is  likely  to  be  good,  and  »} 

{*  performs  forward  pruning  according  to  two  criteria;  its  *} 

{*  worst-case  performance  is  O(Nt),  but  is  usually  0(N).  •} 

{*  »} 
{*  OPTIMAL  contains  the  recursive  tree  search  Findbest,  which  *} 
{*  in  turn  contains  Sort.  *} 


•v>:5 


Type 

Low_Rec 
When 
Proc 
End ; 


Record 
Integer; 
3. .15 


Cutoff  :  Integer;  {  Best  time  so  far.  If  it  can't  } 

l  be  undercut,  prune.  } 

I  :  Integer; 

Remaining  :  Unit_Range;  {  Units  remaining  to  be  processed  } 

Done  :  Boolarray; 

Low_Vec  :  Array[0. .Max_Units]  of  Low_Rec; 

{  Used  in  computing  Lower bound  } 


Function  Findbest  :  Integer; 

{*  Recursive  decision  tree  search,  with  cutoffs.  *) 

. . . . I . . 

Type 


{  Units  not  yet  done,  weights  } 


ND_Rec  =  Record 
U  :  Unit_Range; 

Val  :  Integer 
End; 

ND  Vec  r  Array [Unit  Range]  of  ND_Rec; 


Var 

Getlock,  Best_Path,  Lowerbound,  Pathtime  :  Integer; 

Cursor  :  0. .Max_Units; 

I  :  Unit_Range; 

Notdone  :  ND_Vec ; 

P  :  T_L_Ptr; 

J,  Cum_Delay  :  Integer; 

Procedure  Sort(Var  Tosort  :  ND_Vec;  N  :  Unit  Range); 

{*  Linear  insertion  sort,  in  place.  An  0(N**2)  sort  *} 

{*  makes  sense  here,  since  it  will  be  called  far  *} 

{*  more  times  with  small  N  than  with  large.  This  *} 

{*  sort  beats  Shellsort  and  Quicksort  for  N  less  *} 

{*  than  about  15,  and  N  will  seldom  be  that  large.  *} 

{iiHHimiimmimiiiHmHHHHHiHimHKH) 

Var 

I,  J,  TempVal  ;  Integer; 

TempU  :  Unit_Range; 

Begin 

For  I  :=  1  to  N-1  do  begin  {  Elements  1..I  are  in  order  } 

TempU  :=  Tosort [1+1] .U; 

TempVal  ;=  Tosort [1+1] .Val; 

J  ;=  I; 

While  TempVal  <  Tosort[ J] .Val  do  begin 
Tosort[ J+1] ,U  :=  Tosort[J].U; 

Tosort[ J+1] .Val  ;=  Tosort[ J] .Val ; 

J  :=  J  -  1; 

If  J  <  1  then  Break  {  Nonstandard:  Leave  innermost  loop  } 
End;  {  While  } 

Tosort[ J+1] ,U  :=  TempU; 

Tosort [ J+1] .Val  :=  TempVal 
End  {  For  I  . . .  } 

End; 

Begin  {  Findbest  } 

If  Remaining  =  1  then  begin 

{  Only  one  unit  remains  } 

I  :=  1;  While  Done[I]  do  I  :s  I  +  1; 

Getlock  :=  LMO(t)  +  Delay[I];  {  LMO  =  time  to  acquire  lock  } 

If  Present_time  +  Getlock  <  Cutoff  then 
Cutoff  :=  Present_time  +  Getlock; 

Findbest  :s  Getlock 
End  {  Else  if  Remaining  =  1  ...  } 

Else  begin 


{  More  than  one  unit  remains  } 

Best_Path  :=  Maxint; 

Lowerbound  ;=  0; 

Cursor  :=  0; 

{  Compute  Lowerbound  } 

For  I  :=  1  to  LU_Num  do 

If  Not  Done[I]  then  begin 

{  Linear  insertion  according  to  when  available  } 
Cum_Delay  :=  LMO(I); 

Low_Vec[0] .When  :=  Cum  Delay; 

Low_Vec[0] .Proc  :=  Delaytl); 

J  is  Cursor; 

While  Low_Vec[ J] .When  <  Cum_Delay  do  begin 
Low_Vec[J+1]  :=  Low_Vec[J]; 

J  :=  J  -  1 
End;  {  While  } 

Cursor  :=  Cursor  +  1; 

Low_Vec[J+1]  :=  Low_Vec[0] 

End;  {  End  linear  insertion  } 

Cum_Delay  :=  0; 

For  I  ;s  1  to  Cursor  do  begin 

Cum_Delay  is  Cum_Delay  +  Low_Vec[I] .Proc; 

Lowerbound  is  Max ( Lowerbound ,  Low_Vec[ I] .When  ♦  Cum_Delay); 
Cum_Delay  is  Cum_Del ay  +  Lock_Request_Del ay 
End ; 

{  End  computation  of  Lowerbound  } 

If  Present_time  +  Lowerbound  <  Cutoff  then  begin  {  A  pruning  } 

{  Arrange  those  units  not  processed  } 

{  Generate  weights!  Time  of  next  locking  for  units  } 
{  that  are  unlocked  but  which  will  be  locked  again  } 

{  (Note  crystal  ball).  Processing-time  +  9000  } 

{  for  those  that  are  available  and  will  not  become  } 

{  unavailable,  and  Release-time  +  10000  for  those  } 

t  that  are  presently  locked.  } 

Cursor  is  0; 

For  I  is  1  to  LU_Num  do 

If  Not  Done[I]  then  begin 
Cursor  is  Cursor  +  1; 

Notdonet Cursor ] .U  is  I; 

If  Unitsfl)  =  Nil  then 

Notdonet Cursor). Val  is  Delaytl)  ♦  9000 
Else  if  (Units[ir.Next  s  Nil) 

and  ( Units[I]''.Time  <s  Present_time) 
then  Notdone[Cursor]  .Val  is  Delaytl)  9000 
Else  if  Units[ I]" .Next  s  Nil  then 

Notdone[ Cursor)  .Val  is  Units[I)''.Time  +  10000 
Else  begin 

P  is  Unitstl); 

While  (P~. Next". Time  <s  Present_time) 

and  (P*. Next". Next*. Next  <>  Nil) 
do  P  is  P~ .Next* .Next ; 

{  PT  ( )  } 


‘Vv'*  V’./* *'  .*• 


If  P^.Time  >  Present_time  then 
Notdone [Cursor ].Val  :  =  P^.Time 
{  (  PT  )  } 

Else  if  P*. Next*. Time  >  Present_time  then 

Notdone [Cursor ] .Val  :=  P* .Next* .Time  +  10000 
{  ()  PT  } 

Else  Notdone [Cursor ] .Val  :=  Delay[I3  +  9000 
End  {  Else  } 

End;  {  Then  } 

{  Sort  according  to  weights  } 

Sort (Notdone,  Cursor); 

{  Search  for  optimal  order,  cutting  off  if  equal  to  } 
{  a  previously-computed  lower  bound  or  if  unable  to  } 
{  better  the  best  previous  time.  } 

I  :=  1; 

While  (I  <=  Cursor)  and  (Best_Path  >  Lowerbound)  do  begin 
Getlock  :=  LM0(Notdone[I3  .U)  +  Del  ay  [  Notdone  [  I)  .11] ; 

{  Simulate  processing  the  unit  } 

Done[Notdone[I) ,U3  :=  True; 

Present_time  :=  Present_time  +  Getlock; 

Remaining  :  =  Remaining  -  1; 

{  Recurse  } 

Pathtime  :=  Findbest; 

{  Record  best  found  so  far  } 

If  Pathtime  <  Best_Path  -  Getlock  then 
Best_Path  :=  Pathtime  +  Getlock; 

{  Undo  } 

Done [Notdone [I) ,U3  :=  False; 

Present_time  :=  Present_time  -  Getlock; 

Remaining  :  =  Remaining  +  1; 

{  Increment  loop  control  } 

I  :=  I  +  1 
End  {  While  } 

End;  {  Then  } 

Findbest  :=  Best_Path 
End  {  Else  } 

End;  {  Findbest  } 

. . . . . 

Begin  {  Optimal  } 

{  Initializations  } 

Remaining  :=  LU_Num; 

Cutoff  :=  Maxint; 

Present_Time  :=  0; 

For  I  ;=  i  to  LU_Num  do  begin 
Done[I]  :=  False; 

Avail[l3  s=  Maxint; 

{  Start  all  queues  } 

If  Units[  13  <>  Nil  then  if  Units[I3''.Next  =  Nil  then 
Avail [ 13  :=  Units[I3*.Time 


{  Call  recursive  tree  search  } 

I  :=  Findbest; 

Opteval(FLOAT( Cutoff ) ,  FLOAT( LU_Num) ) ;  {  Record,  for  comparison  } 
Accumulate( Cutoff,  LU_Num,  0);  - 
Summary_Stats( FLOAT( Cutoff) ,  FL0AT( LU_Num) ) 

End;  {  Optimal  } 


End.  {  Module  Locopt  } 


. . . . . . . . . 

{*  Interface  that  supplies  global  identifiers  to  all  those  *} 
{•  program  units  that  need  them.  Important  consts  and  *} 
{•  types  are  included,  but  also  the  files,  lockable  unit  *} 
{*  information  Units,  availability,  processing  delay,  and  •} 
{•  the  scalars  Lock_Request_Delay  (presently  1),  number  of  »} 
{*  lockable  units  LU  No,  and  Present_time.  *} 

{HHiHmiHiHiimmmiiimiiiiHHmmmmmim} 

Interface; 

Unit  Globids(Hax  Units,  Algos,  Unit  Range,  T  L  Ptr,  Time  list, 


Un_vec,  Bool array,  Intarray,  Detailfile,  Summaryfile,  Units, 
Lock_Request_delay ,  Present_time ,  Avail,  Delay,  LU_No) ; 

Const 

Max_Units  =100;  {  Max  lockable  units  (arbitrary)} 

Algos  =  8;  {  Number  of  algorithms  } 

Type 

Unit_Range  =  1 .  .Max_Units ; 

T_L_Ptr  =  ATime_list;  {  Time  node  for  linked  list  } 

Time_list  =  Record 
Time  :  Integer; 

Next  :  T_L_Ptr 
End; 

Un_Vec  =  Array[Unit_Range]  of  T_L_Ptr; 

{  Array  of  time  lists  } 

Boolarray  =  Array[Unit_Range]  of  Boolean; 

{  Type  for  Done,  used  in  subprograms 

} 

Intarray  =  Array [Unit_Range]  of  Integer; 

{  Used  for  Avail  and  Delay  } 

Var 

DetailFile,  SummaryFile  j  Text;  {  Output  files  } 

Units  :  Un  Vec;  {  Availability  of  lockable  units: 
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} 

Lock_Reque3t_Delay  :  Integer;  {  Minimum  lock  acquisition  time 

(value: 1)  } 

Present_tirae  :  Integer;  {  Simulated  clock  } 

Avail,  Delay  :  Intarray;  t  When  available,  Processing  delay  } 

LU  No  :  Integer; 


Begin 
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